Change Boundary Event Type#11293
Conversation
|
|
||
| Boundary events are re-created upon interrupting behavior change because in-place conversion can result in invalid states. An interrupting boundary event must abort its parent activity when triggered, meaning an activity cannot have more than one active interrupting boundary event. Converting an already-triggered non-interrupting boundary event to interrupting in place violates this rule: the parent activity remains in progress, resulting in an interrupting boundary event whose parent is never aborted. Conversely, converting an already-triggered interrupting boundary event to non-interrupting in place leaves it active on an already-aborted parent activity, contradicting the rule that a non-interrupting boundary event must not abort its parent. | ||
|
|
||
| #### Implications of Changing the Boundary Event Type |
There was a problem hiding this comment.
Took me a bit to understand this section. What do you think about the following? We can even wrap it in an alert for more emphasis.
Changing a non-interrupting Boundary Event
Due to technical limitations, changing an ongoing non-interrupting boundary event creates a partially resolvable conflict of type Current Activity Moved out of Path on running workflow instances, which requires manual intervention. This does not apply to interrupting boundary events.
For resolution steps, see Workaround for Non-resolvable and Partially Resolvable Conflicts.
There was a problem hiding this comment.
changing an ongoing non-interrupting boundary event
may imply any change to its configuration (like first execution type). I think it makes sense to mention "type" like I did and give an example.
which requires manual intervention
This is true for every conflict. I think the problem is not manual intervention but rather the limitation that one cannot continue the workflow.
For resolution steps, see
That linked section focuses on a workaround. The resolution steps are mentioned in the first reference to the conflict Current Activity Moved out of Path.
There was a problem hiding this comment.
may imply any change to its configuration (like first execution type). I think it makes sense to mention "type" like I did and give an example.
Make sense, let's keep type
This is true for every conflict. I think the problem is not manual intervention but rather the limitation that one cannot continue the workflow.
Can we put the emphasis on "one cannot continue the workflow"?
That linked section focuses on a workaround. The resolution steps are mentioned in the first reference to the conflict Current Activity Moved out of Path.
So it would become something like this?
Changing a non-interrupting Boundary Event Type
Due to technical limitations, changing an ongoing non-interrupting boundary event type (for example, from Timer to Notification) creates a partially resolvable Current Activity Moved out of Path conflict on running workflow instances. Affected workflow instances cannot be continued. This does not apply to interrupting boundary events.
For more information on how to handle such conflicts, see Workaround for Non-resolvable and Partially Resolvable Conflicts.
4 participants
For 11.12